Six Signs You Are Reviewing a Poorly Written Software Contract

I was recently asked how to recognize that a software contract is poorly written. Upon consideration, I’ve come up with six signs to watch for in order to identify a poorly written software contract.

In my experience, the first sign of a poorly drafted contract is that contract completely confuses the software licensing and SaaS technology models, so that it’s extremely unclear as to what kind of product that the software provider is actually selling. If the product is a software license, the contract should contain a clear license grant confirming the licensee’s rights in the intellectual property and defining the scope of the license. Any hosting, maintenance, technical support, or other services should be made available by separate written agreement (i.e. hosting contract, maintenance contract, technical support contract, professional service contract) but should not be included in the face of the license agreement. On the other hand, if the product is a SaaS agreement, no license grant should be included in the contract and the contract should instead contain a clear grant of access and use rights. The terms “licensor” and licensee” should be absent from the contract. On the other hand, services like hosting and maintenance will generally be included in the contract as the bundle of services provided to the subscriber via subscription, as well as other services such as back-up, disaster recovery, technical support, and transitioning services. In addition, a SaaS agreement will generally include a service level agreement and an acceptable use policy, and it will address the policies and procedures taken to ensure the security of the platform. These technology models are very clear and defined technology frameworks. If the contract merges and mixes up the models, then this is a good indication that the contract is poorly drafted.

A second sign of a poorly drafted software contract is that the contract fails to discuss the concept of “users” and how they are granted, and just refers to an invoice or schedule that lists a number of “users” and assigns a price to that number. Both software licenses and SaaS agreements can provide rights to “users” but the license grant or the access rights grant needs to contemplate “users” in terms of who is authorized to be a “user” and what rights are provided to a “user”. In addition, the contract should explain how users are made available (i.e. individually or in increments), how they can be increased or decreased during the term or a renewal period, and the costs of each user or the user increments. Where users are not addressed in the contract and are only referenced in a schedule, they don’t actually have any rights in either the software or the services and so it’s unclear what is actually being sold by a software provider.

A third sign of a poorly drafted software contract is that the contract provides for periodic rather than up-front billing but fails to address what happens when those periodic payments are late. Is suspension employed at some point after the payment is late? If so, what kind of notice is provided and how is that notice delivered? Is the data still accessible after suspension? If so, what kind of fee is assessed for removing the data after suspension and in what format is it removed? If the data is in the cloud, how fast is it purged? A well-drafted software contract contemplates the potential relationship problems that might arise and defines how those scenarios will be handled rather than leaving them to be dealt with in the future.

A fourth sign of a poorly drafted software contract is that the contract fails to set customer expectations about either the functionality and features of the software in the case of a software license or, alternatively in the case of a SaaS contract or other software services contract, the quality and nature of the services that will be provided. In software services contracts, the value of the relationship is entirely tied to what is being delivered. Hosting contracts and SaaS agreements should generally have service level agreements which carefully define the service level being provided, provide a guaranty as to uptime and define any exceptions to that uptime, and provide a service credit that can be easily applied in a service failure. They should also address in detail the backup services being provided, the security services employed to keep the host or SaaS platform secure, and the disaster recovery services, as well as any transitioning services made available and how those work. Technical support is going to generally be available in software licenses, hosting contracts, and SaaS agreements, so is all of these cases how those services will work will need to be carefully defined. The bottom line is that these services relationship should be defined in detail and not left for future interpretation. A poorly drafted contract is going to be very unclear about what the software provider is providing under the relationship, which creates enormous opportunities for disputes to arise, since there may not really be anything agreed upon in the contract.

A fifth sign of a poorly drafted software contract is that the contract fails to define specifically what version or module of the product the contract even applies to. Few software vendors sell a single product without at some point making available optional features and services that can be “added on” for an additional charge. Many, if not most, contracts fail to fully describe the functionality, features or services that the contract applies to, which creates the potential for disputes as new functions, features, services, and/or products are made available, as the scope of what the original agreement applied to is simply not clear.

Finally, a sixth sign of a poorly drafted software contract is that the contract fails to contemplate and set expectations about what will be required for implementation, how long it will take, what would constitute a successful implementation, what milestones would arise in the implementation and how it would be verified that they were successfully performed, and any responsibilities the customer must meet at defined steps in the process. In multiple user scenarios and in many data-focused software products, implementation is a lengthy and very involved process, yet most software contracts are completely silent about implementation. This sets parties up for disputes over implementation. A poorly drafted contract is going to leave customer expectations for implementation largely undefined.

This list is certainly not exhaustive but provides some guidelines for what to look for in order to identify a poorly drafted software contract.

In summary, a software contract should provide significant clarity on the product or services being sold so that a layperson should be able to understand from the terms how the product or service will work and what kinds of expectations he or she should have about the product or service, the applicable fees, any set-up required, etc. If a contract raises more questions than it answers, then this is a fairly strong indication that the contract is poorly drafted.